上一回，我們聊到解決問題，讓自己的工作能順利進行，筆者想到一個跟解決問題相關的故事。
電影「三個傻瓜」大家看過嗎？電影中有一幕讓筆者印象非常深刻：
主角考上了印度有名的大學，入學第一天校長召集了工學院的學生發表演說，並從回袋拿出一支鋼筆，並向大家說：「這是我讀書時我的校長給我的，作為我第一名畢業的獎勵。這是一支高科技的鋼筆，可以在任何情況下書寫，包含無重力的太空。這支筆造價非常高，非常昂貴。四年之後，你們之中誰第一名畢業，我就將這支鋼筆送給你。」
校長這段話本來是想說來鼓勵這些小菜鳥好好用功，怎料這時主角迸出一句：「太空中沒有重力，為什麼不用鉛筆寫就好呢？」
是呀！問題到底是要「發明在太空中能書寫的鋼筆」，還是要「在太空中寫字」？
筆者在前公司曾不只一次，接到業務緊急打來的「救命電話」。電話中對方總是說，客戶要在某個地方加某個功能，而且很急，不趕快幫他們做，就不跟我們做生意之類的。
頭兩次接到這種電話當然會很緊張，趕快就招兵買馬，把手上工作暫停，趕快幫客戶救命再說。然而幾次下來，我發現這些功能客戶拿去後都會回頭要求修個幾次，我都會心想，這功能不是你們要的嗎？為什麼我們照著做出來以後你們老是感覺不太合用，不然怎麼會一下子又來要修改？該不會…客戶自己也不知道自己要什麼吧？
於是後來我就學會放慢下來，要業務回去問客戶到底想解決什麼問題，在什麼場景下，原來的功能用起來不足在哪？希望達到什麼效果？這些都掌握後，我才開始著手為客戶規劃功能，這才發現，大部份的時候，客戶一開始提的需求（其實也不是需求，是他們自己想出來的 Solution），根本解決不了他們真正遇到的問題。甚至有幾次，我教他們用 excel 的公式直接處理，問題就解決了，程式碼什麼的根本就不用寫。
無碼勝有碼，原來是真的。
筆者曾參加過搞笑談軟工板主 Teddy Chen 的培訓課程，有一次他問大家，寫程式是為了什麼？這時十個有十個都會中計，想都不想就回答：「解決問題。」
我一開始也是這麼認為的。公司請我們來不就是靠寫程式解決問題嗎？後來才發現不完全是的。如果你寫程式是為了解決問題，那你肚子餓時吃大便會不會飽？問題解決啦！為什麼你不吃，要去樓下花一百塊買便當？
欸？對耶？我怎麼沒想過？
又不是包龍星…
包龍星示意圖
建築師 Christopher Alexander（以下簡稱 Alexander）的專長雖然是建築設計，但其模式語言與以模式為導向的思考模式，在 20 世紀末與 21 世紀以來至今，都對軟體業從業人員有很大的影響。
Alexander 認為，在蓋房子時，你要先定義好你的問題，再去找方法來解決。這裡的問題就是 Problem，而 Pattern 就是你找出來的方法。
例如，我要怎麼解決「一個社會集團（如：家庭）的成員之間需要在私密空間之外，透過經常性的非正式接觸，來維持此集團的存在」的問題，他提出來的解法叫做「中心公用區」，亦即，在集團每個人的私密空間圍著的中間處，保留一塊與必經走道相切的區域，讓大家可以用來從事如「偶遇並尬聊」的這種非正式接觸。
至於為什麼非得要在中心，非得要與走道相切不可呢？因為如果在邊邊，那大家就不會在路過時偶遇，這麼一來，每次的相遇都得刻意創造，會有點壓力。而與走道相切，則是如果這塊公用區直接穿過走道的中心，會一直被經過的人「深入打擾」，想使用這裡的人不管要逗留還是休息都會感到不方便。
公用區直接穿過走道的中心示意圖，圖片來源：建築模式語言
上面這個短短的分析過程，恰恰好就說明了 Alexander 的模式語言的基本組成，與他提出來的，以模式為中心來思考對策的工作方式。
上面要解決一個家庭要怎麼維持存在的這件事就是問題（Problem），不想走太遠，不想有太大壓力，不想一直被路過的人打擾，就是面對這個問題的人遭受到的 Force。Force 綜合起來形成的空間，就是我們所在的環境（Context）。所謂模式為中心的思考，就是要用 Context 來定義問題，然後找方法來「套」這個 Context。最後，「中心公用區」就是最後 Alexander 提出來的模式（也就是 Solution）。
在前文有說到，Roy 與 Anna 在面對兩邊統程過於繁瑣，讓各自團隊工作不順，到最後甚至無法好好「做自己的事」的時候，筆者建議他們可以先跳出找戰犯的下游思維，坐下來共商對策。
這時，能商討的可能對策有很多，例如反正活動每個月都要辦，不如 Roy 自已請一個人來專門處理行銷要的技術問題。這個 Solution 適合嗎？如果不適合，為什麼？寫下來，就變成一個 Force。不然，把活動網站外包，節省 Anna 的人力，我們也能對外包商下指導棋，畢竟是我們付錢嘛！這個 Solution 適合嗎？如果不適合，為什麼？寫下來，就變成第二個 Force。我們就這樣一個一個列出不同的 Force，這些 Force 就會形成我們真正面對的 Context，最後，我們一定能找到一個 Solution，套下去之後，感覺與 Context 沒什麼衝突，這就是我們用以模式為中心開展的 Solution。
有了 Solution，我們就來套看看，如果合用就解了，我們就可以回去各自發揮所長，為 KPI 努力了。如果不合用，這時 Context 已經改變，我們就再來找新 Solution 就好。
但與以前不同的是，每一次找的 Solution，都能確保我們過去探索過的 Force 不會被乎略，也就是未來被現在的 Solution「反咬」的機會降低了。這麼一來，日子就可以預期地會比原來好過很多，至少不用再每天吵來吵去了，對吧？
回到肚子餓的議題。各位讀者現在知道了，如果你肚子餓，給你大便你肯定是不會吃的，這是因為你是文明人，大便吃了會生病這點常識還是有的，這就是一種 Force。我們可以綜合口袋深度、現在時間、現在所在地點、個人口味等 Force，來找出最適合現在的 Solution，也許是個燒臘便當，也許是塊菠蘿麵包，我不知道，因為，回到現實面，反正現在肚子餓的人是你，不管是誰造成的，你還是要為自己想辦法的。
再回到公司的議題，公司請你來寫程式，為了什麼？答案呼之欲出了：「發揮所長，解決問題；解決問題的同時，不製造過多的新問題。」
謎之聲：「還是說我們轉行去蓋房子好了？」
iThome鐵人賽
看影片追技術